부록 A. LLM Fit으로 내 컴퓨터에 맞는 로컬 LLM 고르기

검증 메모

이 부록은 2026년 6월 1일 기준 LLM Fit 공식 웹사이트와 GitHub 문서를 함께 확인해 정리한 원고입니다. 도구 이름은 공식 문서에서 llmfit으로 표기되지만, 본문에서는 독자의 이해를 위해 “LLM Fit”으로 병기합니다.

Part 2에서 모델 선택의 원칙을 배웠습니다. 파라미터 수가 크다고 무조건 좋은 모델은 아니고, 양자화가 낮다고 무조건 나쁜 모델도 아니며, 컨텍스트가 길다고 항상 실무에 유리한 것도 아닙니다. 그러나 막상 모델을 고르려고 하면 다시 어려워집니다. Hugging Face에는 너무 많은 모델이 있고, 같은 모델도 여러 양자화 버전으로 나뉘며, 어떤 모델은 LM Studio에서 잘 보이지만 어떤 모델은 Ollama나 llama.cpp에서 더 편하게 실행됩니다.

초보자가 가장 자주 겪는 문제는 “다운로드한 뒤에야 알게 된다”는 것입니다. 멋져 보이는 모델을 발견합니다. 파일 크기가 10GB가 넘습니다. 한참 기다려 다운로드합니다. 실행해 봅니다. 그런데 메모리가 부족하거나, 첫 토큰이 나오기까지 오래 걸리거나, 초당 토큰 수가 너무 낮아 실무에서 쓰기 어렵습니다. 이 과정을 몇 번 반복하면 로컬 AI 자체가 피곤하게 느껴집니다.

LLM Fit은 이 시행착오를 줄이기 위한 도구입니다. “내 컴퓨터에서 어떤 모델이 실제로 돌아갈 수 있는지 먼저 계산해 주는 모델 선택 도구”입니다. LLM Fit은 CPU, RAM, GPU, VRAM 같은 하드웨어 정보를 읽고, 모델 데이터베이스와 비교해 모델별 실행 가능성, 예상 속도, 권장 양자화, 컨텍스트, Fit 등급을 보여 줍니다. 그래서 모델을 다운로드하기 전에 후보를 좁힐 수 있습니다.

부록A는 “LLM을 어떻게 선택해야 하는가”를 실전 절차로 정리합니다. 어떤 점수를 먼저 볼지, 어떤 등급부터 거를지, 자동완성용 모델과 채팅용 모델을 어떻게 다르게 볼지, GPU 업그레이드를 고민할 때 어떤 식으로 판단할지까지 차근차근 살펴보겠습니다.

[이미지 A-1] “모델 선택 시행착오”와 “LLM Fit 기반 선택” 비교 그림.

A.1 모델 선택은 왜 어려운가

로컬 LLM 선택이 어려운 이유는 변수가 많기 때문입니다. 모델을 고를 때는 최소한 다섯 가지를 같이 봐야 합니다.

• 첫째, 모델의 목적입니다. 일반 채팅 모델인지, 코딩 모델인지, 추론 모델인지, 멀티모달 모델인지에 따라 사용성이 달라집니다.
• 둘째, 파라미터 수입니다. 대체로 큰 모델은 더 많은 패턴을 담을 수 있지만, 실행 비용도 커집니다.
• 셋째, 양자화입니다. Q8, Q6, Q5, Q4처럼 압축 정도에 따라 품질과 메모리 사용량이 달라집니다.
• 넷째, 컨텍스트 길이입니다. 코딩 작업에서는 현재 파일뿐 아니라 관련 타입, 테스트, 문서까지 함께 넣어야 하는 경우가 많습니다.
• 다섯째, 내 하드웨어입니다. 같은 모델이라도 RTX GPU, Apple Silicon, CPU-only 환경에서 체감 성능이 완전히 달라집니다.

문제는 이 변수들이 서로 독립적이지 않다는 점입니다. 파라미터 수가 큰 모델을 고르면 품질은 좋아질 수 있지만 메모리 사용량이 늘어납니다. 컨텍스트를 길게 열면 긴 파일을 다루기 쉬워지지만 KV 캐시 때문에 메모리를 더 씁니다. 양자화를 낮추면 모델이 가벼워지지만 품질 손실이 생길 수 있습니다. VRAM이 부족하면 일부 레이어가 RAM으로 넘어가며 속도가 떨어질 수 있습니다.

그래서 로컬 모델 선택은 “가장 좋은 모델 찾기”가 아닙니다. 더 정확히는 “내 장비와 내 작업에 맞는 타협점 찾기”입니다. 이 관점이 중요합니다. 클라우드 모델을 고를 때는 대개 모델 성능과 비용을 봅니다. 로컬 모델을 고를 때는 여기에 하드웨어 적합성이라는 축이 하나 더 붙습니다. 아무리 좋은 모델이라도 내 장비에서 1초에 한두 토큰밖에 나오지 않는다면 코딩 도구로 쓰기 어렵습니다.

반대로 너무 작은 모델만 고르면 속도는 빠르지만 작업 품질이 낮을 수 있습니다. 자동완성에는 괜찮은데, 버그 분석이나 리팩터링에서는 자꾸 엉뚱한 답을 할 수 있습니다. 따라서 로컬 코딩 워크플로에서는 보통 하나의 모델만 쓰기보다 목적별로 모델을 나눕니다. 자동완성은 빠른 모델, 채팅은 조금 더 큰 모델, 에이전트 작업은 코딩 성능과 컨텍스트가 균형 잡힌 모델을 쓰는 식입니다.

[표 A-1] 로컬 LLM 선택 변수 정리.

A.2 LLM Fit이 답해 주는 질문

LLM Fit이 답해 주는 질문은 단순합니다. “이 모델이 내 컴퓨터에서 돌아갑니까?”입니다. 그러나 실제로는 그보다 더 많은 질문에 답합니다. “돌아가기는 하지만 실무 속도가 나옵니까?”, “어느 양자화 버전을 써야 합니까?”, “GPU에 올릴 수 있습니까, 아니면 RAM으로 넘쳐서 느려집니까?”, “컨텍스트를 얼마나 열 수 있습니까?”, “이 모델을 쓰려면 어떤 하드웨어가 필요합니까?” 같은 질문입니다.

LLM Fit은 실행되면 먼저 시스템 정보를 확인합니다. CPU 이름과 코어 수, 전체 RAM과 사용 가능한 RAM, GPU와 VRAM 정보를 확인합니다. NVIDIA, AMD, Intel, Apple Silicon 같은 환경을 감지하고, 여러 GPU가 있는 경우도 고려합니다. 그다음 모델 데이터베이스와 하드웨어 정보를 비교합니다. 이 과정에서 모델별 파라미터 수, 양자화 단계, 컨텍스트, 실행 모드, 예상 속도 등을 계산합니다.

중요한 점은 LLM Fit이 단순히 “가능”과 “불가능”만 보여 주지 않는다는 것입니다. 모델을 Quality, Speed, Fit, Context 같은 여러 축으로 점수화하고, 최종적으로 종합 순위를 보여 줍니다. 이 점수가 완벽한 정답이라는 뜻은 아닙니다. 실제 성능은 런타임, 드라이버, 백엔드, 운영체제 상태, 동시에 실행 중인 앱, 모델 구현에 따라 달라질 수 있습니다. 그러나 다운로드 전에 후보를 줄이는 데에는 매우 유용합니다.

LLM Fit을 모델 선택에 활용할 때의 가장 큰 장점은 짐작을 줄여줍니다. “이 정도면 되겠지”가 아니라 “내 장비 기준으로 어느 정도 Fit인지”를 먼저 봅니다. “이 GPU를 사면 70B 모델이 잘 돌까”가 아니라 “시뮬레이션했을 때 어떤 모델까지 Good 또는 Perfect가 되는지”를 확인합니다. 이 차이가 로컬 AI 입문자의 시행착오를 크게 줄여 줍니다.

[이미지 A-2] LLM Fit의 판단 흐름.

A.3 설치보다 먼저 정해야 할 것

도구를 설치하기 전에 먼저 정해야 할 것이 있습니다. 바로 “내가 모델을 어디에 쓰려는가”입니다. 목적이 없으면 점수표를 봐도 선택하기 어렵습니다. 초보자는 점수가 가장 높은 모델을 고르기 쉽지만, 실제로는 작업 목적에 따라 좋은 모델이 달라집니다.

자동완성용 모델은 무엇보다 속도가 중요합니다. 코드를 입력하는 도중에 제안이 늦게 나오면 흐름이 끊깁니다. 이 경우에는 아주 큰 모델보다 작은 코딩 모델이 더 나을 수 있습니다. 채팅용 모델은 설명 능력과 응답 속도의 균형이 중요합니다. 현재 파일을 설명하거나, 함수 단위로 리팩터링 방향을 묻거나, 에러 원인을 같이 추적하는 작업입니다. 에이전트용 모델은 코드 이해력, 지시 준수, 도구 사용 능력, 컨텍스트 처리 능력이 더 중요합니다.

추론용 모델은 별도로 봐야 합니다. 복잡한 알고리즘 문제, 아키텍처 판단, 여러 조건을 따져야 하는 설계 질문에서는 품질이 더 중요합니다. 다만 로컬 환경에서 추론 모델은 속도가 느릴 수 있고, 작은 추론 모델은 답변이 길어져 실무 흐름을 방해할 수 있습니다. 따라서 로컬 추론 모델은 “항상 켜 두는 기본 모델”이라기보다 “필요할 때 쓰는 보조 모델”에 가깝게 보는 편이 현실적입니다.

설치 전에는 다음 세 가지를 정리해 두면 좋습니다.

1. 이 모델을 자동완성, 채팅, 리팩터링, 에이전트, 문서화 중 어디에 쓸 것인가.
2. 답변 속도가 중요한가, 코드 품질이 중요한가, 긴 컨텍스트가 중요한가.
3. 내 장비에서 GPU를 쓸 수 있는가, 아니면 CPU와 RAM 중심으로 실행해야 하는가.

이 세 가지가 정리되면 LLM Fit의 결과를 훨씬 쉽게 읽을 수 있습니다. 점수표 전체를 보는 것이 아니라, 내 목적에 맞는 후보만 보면 되기 때문입니다.

[체크리스트 A-1] 모델 선택 전 질문 체크리스트.

A.4 LLM Fit 설치와 첫 실행

LLM Fit은 터미널에서 사용하는 도구입니다. Windows에서는 Scoop을 통해 설치할 수 있고, macOS와 Linux에서는 Homebrew, 설치 스크립트, uv 또는 pip, Docker/Podman 같은 방식을 사용할 수 있습니다. 설치 방식은 계속 바뀔 수 있으므로, 출간 시점에는 공식 문서를 기준으로 명령을 다시 확인해야 합니다.

Windows에서 Scoop이 이미 설치되어 있다면 다음처럼 설치할 수 있습니다.

scoop install llmfit

[이미지 A-3] Windows 11 PowerShell 터미널에서 Scoop으로 llmfit 설치

[참고]만약 윈도우에 scoop 설치 전이라 아래와 같은 메시지가 나오면,

PS C:\Users\bj> scoop install llmfit
scoop : 'scoop' 용어가 cmdlet, 함수, 스크립트 파일 또는 실행할 수 있는 프로그램 이름으로 인식되지 않습니다. 이름이 정확한지 확인하고 경로가 포함된 경우 경로가
올바른지 검증한 다음 다시 시도하십시오.
위치 줄:1 문자:1
+ scoop install llmfit
+ ~~~~~
    + CategoryInfo          : ObjectNotFound: (scoop:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Windows11 파워셀에서

 Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
  irm get.scoop.sh | iex
  scoop --version
  scoop install llmfit
  llmfit --version

명령을 순서대로 실행해서 scoop을 설치하시고 llmfit을 다시 설치해주세요.

macOS나 Linux에서는 Homebrew를 사용할 수 있습니다.

brew install AlexsJones/llmfit/llmfit

환경에 따라 다음 명령도 가능할 수 있습니다.

brew install llmfit

uv를 쓰는 개발자라면 다음처럼 설치하거나 실행할 수 있습니다.

uv tool install -U llmfit
uvx llmfit

설치가 끝나면 먼저 시스템 정보를 확인합니다.

llmfit system

이 명령은 내 컴퓨터의 CPU, RAM, GPU, VRAM 등 모델 선택에 필요한 기본 정보를 보여 줍니다. 여기서 가장 먼저 볼 것은 전체 RAM과 사용 가능한 RAM, GPU 이름, VRAM입니다. 특히 노트북에서는 운영체제와 브라우저, IDE가 이미 메모리를 많이 쓰고 있을 수 있습니다. 전체 RAM이 32GB라고 해도 실제로 모델 실행에 쓸 수 있는 메모리는 그보다 적을 수 있습니다.

그다음 아무 인자 없이 실행하면 TUI, 즉 터미널 사용자 인터페이스가 열립니다.

llmfit

TUI 상단에는 하드웨어 정보가 표시되고, 아래에는 모델 목록이 표시됩니다. 모델 목록에는 모델 이름, provider, 파라미터 수, 종합 점수, 예상 tokens/sec, 추천 양자화, 디스크 크기, 실행 모드, 메모리 사용률, 컨텍스트, Fit 등급, use case 등이 나타납니다. 처음 보면 정보가 많아 보이지만, 실제로는 몇 가지 열만 먼저 보면 됩니다. 초보자는 Fit, Score, tok/s, Quant, Ctx, Use Case 순서로 보는 것이 좋습니다.

[실습 화면 A-1] llmfit system 출력 화면과 llmfit TUI 첫 화면.

A.5 모델 표를 읽는 순서

LLM Fit의 모델 표를 처음 볼 때는 모든 열을 한 번에 이해하려고 하지 않아도 됩니다. 모델 선택에서 중요한 열은 우선순위가 있습니다. 저는 다음 순서로 보는 것을 권장합니다.

첫째, Fit 등급입니다. Fit은 이 모델이 내 메모리 환경에 얼마나 잘 맞는지를 보여 줍니다. Perfect나 Good은 후보로 볼 수 있고, Marginal은 조심해서 테스트해야 하며, Too Tight는 초보자에게 권하지 않습니다. 실행이 된다고 해도 컨텍스트를 줄이거나, 속도가 너무 느리거나, 다른 앱을 끄지 않으면 불안정할 수 있습니다.

둘째, Use Case입니다. 코딩 작업을 하려면 Coding 또는 코드 생성에 강한 모델을 우선 봅니다. 일반 Chat 모델도 간단한 설명은 가능하지만, 자동완성이나 리팩터링에서는 코딩 특화 모델이 더 안정적일 수 있습니다. 멀티모달 모델은 이미지 입력이 필요한 작업에 유리하지만, 코드 자동완성의 기본 모델로는 과할 수 있습니다.

셋째, 예상 tokens/sec입니다. 이 값은 모델이 초당 몇 개의 토큰을 생성할지 추정한 값입니다. 절대값으로 맹신하면 안 되지만, 후보 간 상대 비교에는 도움이 됩니다. 자동완성처럼 즉시성이 중요한 작업은 tok/s를 더 중요하게 봐야 합니다. 반대로 하루에 몇 번만 쓰는 복잡한 추론 질문이라면 속도를 조금 양보하고 품질을 볼 수 있습니다.

넷째, Quant입니다. LLM Fit은 내 하드웨어에 맞는 양자화 후보를 추천합니다. Q8에 가까울수록 일반적으로 품질 보존이 좋지만 메모리를 더 씁니다. Q4나 Q5는 로컬 환경에서 자주 쓰는 현실적인 타협점입니다. Q2나 Q3까지 내려가야 겨우 실행되는 모델이라면, 더 작은 모델의 Q4나 Q5가 실제로 더 나을 수 있습니다.

다섯째, Context입니다. 코딩에서는 컨텍스트가 중요합니다. 한 함수만 다룰 때는 짧아도 되지만, 여러 파일을 같이 보거나 README와 테스트를 함께 넣으려면 더 긴 컨텍스트가 필요합니다. 다만 컨텍스트를 길게 열수록 메모리 사용량도 늘 수 있으므로, 무조건 긴 모델을 고르는 것이 답은 아닙니다.

[표 제안 A-2] LLM Fit 모델 표 읽는 순서. 열은 “우선순위”, “열 이름”, “무엇을 뜻하는가”, “초보자 판단법”으로 구성합니다. 행은 Fit, Use Case, tok/s, Quant, Context, Score, Memory %, Run Mode를 넣습니다.

A.6 네 가지 점수: Quality, Speed, Fit, Context

LLM Fit은 모델을 여러 차원으로 평가합니다. 대표적인 축은 Quality, Speed, Fit, Context입니다. 이 네 가지를 이해하면 종합 점수를 더 잘 해석할 수 있습니다.

Quality는 모델 자체의 일반적인 품질을 나타내는 축입니다. 파라미터 수, 모델 계열의 평판, 벤치마크 성능, 작업 목적과의 적합성 등이 영향을 줍니다. 다만 Quality가 높다고 항상 내 작업에서 가장 좋은 모델이라는 뜻은 아닙니다. 로컬 코딩에서는 품질이 조금 낮아도 빠르고 안정적인 모델이 더 자주 쓰일 수 있습니다.

Speed는 내 하드웨어에서의 예상 생성 속도입니다. 중요한 점은 이 속도가 단순히 모델 이름만 보고 정해지는 것이 아니라, GPU 메모리 대역폭, 백엔드, 양자화, 실행 모드에 따라 달라진다는 점입니다. 같은 모델도 GPU에 온전히 올라가면 빠르지만, 일부가 시스템 RAM으로 넘어가면 느려질 수 있습니다.

Fit은 메모리 적합도를 나타냅니다. 너무 빡빡하게 메모리를 쓰는 모델은 작은 환경 변화에도 불안정할 수 있습니다. IDE, 브라우저, Docker, 데이터베이스, 디자인 툴을 동시에 켜 둔 개발 환경에서는 여유 메모리가 중요합니다. 그래서 Fit이 좋은 모델은 단순히 “실행 가능”을 넘어 “개발 작업 중에도 버틸 가능성이 높은 모델”에 가깝습니다.

Context는 실제로 사용할 수 있는 컨텍스트 길이와 관련된 점수입니다. 코딩 모델은 코드 조각만 보는 것이 아니라 관련 파일과 문서를 함께 봐야 품질이 올라갑니다. 긴 컨텍스트는 프로젝트 이해에 도움이 되지만, 작은 모델에서는 오히려 집중도가 떨어질 수 있습니다. 따라서 컨텍스트 점수는 “길수록 무조건 좋다”가 아니라 “내 작업에 필요한 만큼 충분한가”로 봐야 합니다.

네 점수의 가중치는 사용 목적에 따라 달라집니다. 채팅 모델은 속도가 더 중요할 수 있고, 추론 모델은 품질이 더 중요할 수 있으며, 코딩 모델은 품질과 속도의 균형이 중요합니다. 이 부분이 LLM Fit을 단순 모델 목록보다 유용하게 만드는 지점입니다. 같은 하드웨어에서도 목적을 바꾸면 추천 모델의 우선순위가 달라질 수 있기 때문입니다.

[이미지 A-4] Quality, Speed, Fit, Context 네 축을 레이더 차트처럼 보여 주는 그림.

A.7 Fit 등급을 실무 기준으로 해석하기

Fit 등급은 모델 선택에서 가장 먼저 봐야 하는 신호입니다. Perfect, Good, Marginal, Too Tight 같은 등급은 모델이 내 하드웨어에 얼마나 잘 맞는지 알려 줍니다. 여기서 중요한 것은 “돌아간다”와 “쓸 만하다”를 구분하는 것입니다.

Perfect는 메모리 여유가 충분하고, 해당 모델이 내 장비에서 편하게 실행될 가능성이 높은 상태입니다. 자동완성이나 자주 쓰는 채팅 모델은 가능하면 Perfect 또는 Good에서 고르는 것이 좋습니다. 매일 반복해서 쓰는 도구는 안정성이 중요하기 때문입니다.

Good은 실무 후보로 충분히 볼 수 있는 등급입니다. 메모리를 꽤 사용하지만, 여전히 현실적인 범위 안에 들어오는 모델입니다. 로컬 코딩에서는 Good 등급이 가장 실용적인 경우가 많습니다. 최고 품질 모델을 억지로 돌리는 것보다, Good 등급 모델을 안정적으로 쓰는 편이 개발 흐름에 더 좋습니다.

Marginal은 조심해서 다뤄야 합니다. 실행은 가능할 수 있지만 메모리 여유가 부족하거나, CPU-only 실행이라 속도가 느리거나, 컨텍스트를 줄여야 할 수 있습니다. 실험용으로는 괜찮지만 기본 워크플로에 넣기 전에는 반드시 실제 작업으로 테스트해야 합니다. 특히 자동완성용으로 Marginal 모델을 쓰면 제안이 늦어서 오히려 방해가 될 수 있습니다.

Too Tight는 초보자라면 피하는 것이 좋습니다. 메모리가 부족해 정상 실행이 어렵거나, 실행되더라도 매우 불안정할 가능성이 있습니다. 로컬 AI에 익숙해진 뒤 컨텍스트를 낮추거나, 양자화를 낮추거나, 런타임 설정을 세밀하게 조정해 실험해 볼 수는 있습니다. 하지만 처음 모델을 고르는 단계에서는 시간을 아끼는 편이 낫습니다.

[표 A-3] Fit 등급 실무 해석표.

실무에서는 다음 원칙을 추천합니다. 자동완성은 Perfect 우선, 채팅은 Perfect 또는 Good, 에이전트 작업은 Good 이상을 우선으로 봅니다. Marginal은 성능 테스트를 통과했을 때만 제한적으로 씁니다. Too Tight는 다운로드하지 않습니다. 이 원칙만 지켜도 불필요한 시행착오를 많이 줄일 수 있습니다.

A.8 양자화는 “품질”이 아니라 “타협점”으로 봐야 합니다

양자화는 로컬 LLM에서 가장 중요한 개념 중 하나입니다. 모델은 원래 높은 정밀도의 숫자로 가중치를 저장합니다. 양자화는 이 숫자를 더 낮은 비트로 표현해 모델 크기와 메모리 사용량을 줄이는 방식입니다. 쉽게 말하면 모델을 압축해 내 컴퓨터에서 실행하기 쉽게 만드는 기술입니다.

Q8은 상대적으로 품질 보존이 좋지만 메모리를 많이 씁니다. Q6, Q5, Q4로 내려갈수록 메모리는 줄어들고 실행 가능성은 높아지지만, 품질 손실 가능성도 커집니다. 로컬 환경에서는 Q4나 Q5가 현실적인 타협점이 되는 경우가 많습니다. 다만 모델과 작업에 따라 차이가 있으므로, 숫자만 보고 고정적으로 판단하면 안 됩니다.

초보자가 자주 하는 실수는 “큰 모델의 낮은 양자화”를 무조건 선호하는 것입니다. 예를 들어 큰 모델을 Q2로 겨우 돌리는 것보다, 한 단계 작은 모델을 Q4나 Q5로 안정적으로 돌리는 편이 더 나을 수 있습니다. 특히 코딩에서는 문법 정확성, 지시 준수, 짧은 응답의 안정성이 중요합니다. 낮은 양자화에서 코드 세부가 흔들리면 실무에서는 검토 비용이 커집니다.

LLM Fit의 장점은 이 양자화 선택을 자동으로 후보화해 준다는 점입니다. 최고 품질인 Q8부터 시작해, 메모리에 들어가지 않으면 Q6, Q5, Q4, Q3, Q2 식으로 내려가며 내 장비에 맞는 지점을 찾습니다. 또한 컨텍스트까지 고려하기 때문에, 단순 파일 크기보다 실무에 가까운 판단을 할 수 있습니다.

양자화를 볼 때는 다음 순서로 생각하면 됩니다. 먼저 Good 이상 Fit이 나오는지 봅니다. 그다음 추천 Quant가 Q4 이상인지 봅니다. Q5나 Q6가 가능하면 더 좋습니다. Q2나 Q3까지 내려가야 한다면 같은 계열의 더 작은 모델을 함께 비교합니다. 마지막으로 실제 코딩 프롬프트로 테스트합니다.

[표 A-4] 양자화 선택 가이드.

A.9 컨텍스트 길이는 작업 단위로 정해야 합니다

컨텍스트 길이는 모델이 한 번에 볼 수 있는 정보량입니다. 코딩 작업에서는 컨텍스트가 매우 중요합니다. 함수 하나만 보고 고치는 작업과, 여러 파일을 읽고 기능을 추가하는 작업은 필요한 컨텍스트가 다릅니다. README, 타입 정의, 테스트 코드, 에러 로그까지 함께 넣어야 한다면 컨텍스트가 더 필요합니다.

하지만 컨텍스트는 공짜가 아닙니다. 컨텍스트를 길게 열수록 메모리 사용량이 늘 수 있고, 응답 속도도 느려질 수 있습니다. 작은 모델에서는 긴 컨텍스트를 줬을 때 오히려 중요한 지시를 놓칠 수 있습니다. 따라서 컨텍스트는 “최대한 길게”가 아니라 “작업에 충분하게” 잡아야 합니다.

자동완성은 보통 긴 컨텍스트가 필요하지 않습니다. 현재 파일의 근처 코드와 함수 시그니처, 타입 힌트 정도로도 충분한 경우가 많습니다. 반면 리팩터링이나 버그 분석은 관련 파일과 테스트가 필요할 수 있습니다. 프로젝트 구조를 이해시키는 작업은 폴더 구조, 핵심 파일, README 일부가 필요합니다.

LLM Fit에서는 --max-context 같은 옵션을 사용해 메모리 추정에 사용할 컨텍스트 길이를 제한할 수 있습니다. 예를 들어 4K 컨텍스트 기준으로 후보를 보고 싶은지, 8K 기준으로 보고 싶은지에 따라 추천 결과가 달라질 수 있습니다. TUI의 Plan mode에서도 컨텍스트 값을 바꿔 하드웨어 요구량이 어떻게 달라지는지 확인할 수 있습니다.

llmfit --max-context 4096 fit --perfect -n 5
llmfit --max-context 8192 recommend --json --limit 5

실무 기준으로는 자동완성용 모델은 짧고 빠르게, 채팅용 모델은 중간 컨텍스트, 프로젝트 이해나 에이전트 작업은 더 긴 컨텍스트를 고려합니다. 다만 로컬 모델이 컨텍스트를 많이 받는다고 프로젝트를 완벽히 이해하는 것은 아닙니다. Part 4에서 설명했듯이, 좋은 결과는 긴 컨텍스트보다 좋은 컨텍스트 설계에서 나옵니다.

[표 제안 A-5] 작업 유형별 권장 컨텍스트 판단표. 행은 자동완성, 함수 설명, 파일 리팩터링, 버그 분석, 테스트 생성, 프로젝트 구조 이해, 에이전트 작업으로 구성합니다. 열은 “필요 컨텍스트”, “속도 중요도”, “추천 모델 성향”, “주의점”으로 구성합니다.

A.10 Use Case로 후보를 먼저 줄이기

모델 표에는 use case가 표시됩니다. 초보자는 여기서 후보를 크게 줄일 수 있습니다. 내가 하려는 작업이 코딩이라면 Coding 모델을 먼저 봅니다. 간단한 대화와 설명이 목적이면 Chat 모델도 후보가 됩니다. 복잡한 추론이 필요하면 Reasoning 모델을 봅니다. 이미지 입력이 필요하면 Multimodal 모델을 봅니다. 임베딩은 RAG나 검색용으로 쓰는 별도 모델입니다.

코딩 책의 독자라면 우선 Coding을 중심으로 보면 됩니다. 자동완성, 함수 생성, 테스트 작성, 리팩터링, 버그 분석은 코딩 특화 모델이 유리할 수 있습니다. 다만 모든 Coding 모델이 한국어 설명을 잘하는 것은 아닙니다. 한국어 설명이 필요한 독자라면 후보를 실제로 테스트해야 합니다.

다음은 CLI에서 코딩용 추천 후보를 JSON으로 보는 예시입니다.

llmfit recommend --json --use-case coding --limit 3

TUI에서는 /로 검색하고, s로 정렬 기준을 바꾸고, f로 Fit 수준을 필터링할 수 있습니다. 예를 들어 먼저 Fit을 Good 이상으로 좁히고, use case 또는 모델 이름으로 검색한 뒤, Score나 tok/s 기준으로 정렬해 후보를 봅니다. 모델 후보가 너무 많을 때는 provider나 모델 패밀리로 검색해도 됩니다. Qwen, Gemma, Llama, DeepSeek, Mistral처럼 관심 있는 모델 계열을 검색하는 방식입니다.

여기서 한 가지 주의할 점이 있습니다. 모델 계열의 평판만 보고 고르면 안 됩니다. 같은 계열이라도 크기, 양자화, instruct 여부, coder 여부, 런타임 지원 여부에 따라 체감이 달라집니다. 예를 들어 “Qwen 계열이 좋다”는 말보다 “내 장비에서 Good 이상으로 뜨는 Qwen 코딩 모델 중, Q4 이상 양자화와 충분한 tok/s가 나오는 후보”가 더 정확한 선택 기준입니다.

[실습 화면 A-2] LLM Fit TUI에서 f로 Good 필터를 적용하고, /로 “Qwen” 또는 “Coder”를 검색한 뒤, Score 기준으로 정렬한 화면. 후보 3개에 번호를 붙여 비교 대상으로 표시합니다.

A.11 비교 기능으로 최종 후보를 고르는 법

모델 후보가 3개 정도로 줄어들면 비교가 필요합니다. 이때 중요한 것은 “점수 1등”을 무조건 고르지 않는 것입니다. 후보마다 장단점이 다릅니다. 어떤 모델은 품질 점수가 높지만 느릴 수 있고, 어떤 모델은 속도는 빠르지만 컨텍스트가 짧을 수 있습니다. 어떤 모델은 Fit이 좋지만 코딩 특화가 약할 수 있습니다.

LLM Fit의 TUI에서는 모델을 표시하고 비교할 수 있습니다. 한 모델을 표시한 뒤 다른 모델과 나란히 비교하면 Score, tok/s, Fit, 메모리 사용률, 파라미터 수, 실행 모드, 컨텍스트, 양자화 같은 값을 한눈에 볼 수 있습니다. 이 기능은 초보자에게 특히 좋습니다. 모델 선택을 감으로 하지 않고, 기준을 놓고 비교할 수 있기 때문입니다.

비교할 때는 다음 질문을 던져 보세요.

1. 두 모델 중 어떤 모델이 내 목적에 더 맞습니까?
2. 속도 차이가 실제 작업 흐름에 영향을 줄 정도입니까?
3. Fit 등급이 더 안정적인 모델은 무엇입니까?
4. 추천 양자화가 너무 낮지는 않습니까?
5. 컨텍스트 길이가 내 작업에 충분합니까?
6. 라이선스가 내 사용 목적에 맞습니까?

마지막 질문은 특히 중요합니다. 로컬에서 실행할 수 있다고 해서 라이선스까지 자동으로 해결되는 것은 아닙니다. 개인 실험, 사내 PoC, 상용 제품 내장, 고객 데이터 처리 등 목적에 따라 모델 라이선스를 따로 확인해야 합니다. LLM Fit이 라이선스 정보를 보여 주더라도, 실제 도입 전에는 원 모델 카드와 라이선스 문서를 확인해야 합니다.

[표 A-6] 모델 후보 비교표.

실무에서는 1등 모델 하나만 받지 말고 후보 2~3개를 다운로드해 같은 프롬프트로 테스트하는 것을 권장합니다. 모델 선택 도구는 후보를 줄여 주는 도구이지, 최종 품질 검수까지 대신해 주는 도구는 아닙니다. 특히 코딩 모델은 실제 프로젝트 코드로 테스트해야 합니다.

A.12 Plan mode와 하드웨어 시뮬레이션으로 업그레이드 판단하기

로컬 AI를 쓰다 보면 자연스럽게 하드웨어 업그레이드를 고민하게 됩니다. VRAM이 8GB라서 아쉽고, 16GB면 나을지, 24GB면 충분할지, 64GB RAM Mac으로 바꾸면 체감이 클지 궁금해집니다. 이때 커뮤니티 글만 보고 판단하면 위험합니다. 다른 사람의 워크플로와 내 워크플로가 다르고, 같은 GPU라도 런타임과 모델 설정에 따라 결과가 달라지기 때문입니다.

LLM Fit의 Plan mode는 질문을 뒤집습니다. 일반 모드가 “내 하드웨어에서 어떤 모델이 맞는가”를 묻는다면, Plan mode는 “이 모델을 쓰려면 어떤 하드웨어가 필요한가”를 묻습니다. 특정 모델에서 Plan mode를 열면 최소 및 권장 VRAM, RAM, CPU 코어, 가능한 실행 경로를 추정해 볼 수 있습니다. 컨텍스트, 양자화, 목표 tokens/sec 같은 값을 바꿔 요구 하드웨어가 어떻게 달라지는지도 확인할 수 있습니다.

하드웨어 시뮬레이션은 한 걸음 더 나아갑니다. RAM, VRAM, CPU 코어 수를 임의로 바꿔 다른 장비를 가진 것처럼 모델 목록을 다시 계산합니다. 예를 들어 현재 16GB RAM 노트북을 쓰고 있다면, 32GB RAM이나 64GB RAM으로 바꿨을 때 어떤 모델이 Good 이상으로 올라오는지 볼 수 있습니다. 12GB GPU와 24GB GPU의 차이도 후보 모델 기준으로 비교할 수 있습니다.

이 기능은 업그레이드 결정을 훨씬 현실적으로 만들어 줍니다. “좋은 GPU를 사면 좋겠지”가 아니라 “내가 실제로 쓰고 싶은 모델들이 이 GPU에서 얼마나 좋아지는가”를 볼 수 있기 때문입니다. 만약 내가 자주 쓰는 모델이 이미 현재 장비에서 Good으로 잘 돈다면, 업그레이드 우선순위는 낮을 수 있습니다. 반대로 꼭 쓰고 싶은 모델들이 모두 Too Tight라면, 필요한 VRAM과 RAM을 기준으로 장비를 고를 수 있습니다.

[이미지 제안 A-4] 하드웨어 시뮬레이션 전후 비교 화면. 왼쪽은 현재 장비 기준 Fit 분포, 오른쪽은 64GB RAM + 24GB VRAM 시뮬레이션 기준 Fit 분포를 보여 줍니다. 핵심 메시지는 “업그레이드 전, 실행 가능한 모델 변화부터 확인한다”입니다.

하드웨어 업그레이드 판단에는 다음 절차를 권장합니다.

1. 현재 장비에서 내가 쓰고 싶은 모델 후보를 확인합니다.
2. 후보가 Perfect 또는 Good인지 확인합니다.
3. Marginal 또는 Too Tight가 많다면 Plan mode로 필요한 하드웨어를 봅니다.
4. 하드웨어 시뮬레이션으로 16GB, 24GB, 32GB VRAM 같은 현실적인 옵션을 비교합니다.
5. Community Leaderboard에서 실제 사용자 측정값이 있는지 확인합니다.
6. 업그레이드 비용과 실제로 늘어나는 사용 가능 모델을 비교합니다.

업그레이드의 목적은 숫자 자랑이 아닙니다. 매일 쓰는 워크플로가 빨라지고 안정적이어야 의미가 있습니다. 따라서 장비를 사기 전에 “내 작업에서 어떤 모델을 더 쓸 수 있게 되는가”를 먼저 확인해야 합니다.

A.13 Community Leaderboard는 추정값의 보정 장치입니다

LLM Fit의 기본 모델 표는 하드웨어 정보와 모델 정보를 바탕으로 속도와 적합도를 추정합니다. 이 추정은 후보를 줄이는 데 유용하지만, 실제 성능과 항상 같을 수는 없습니다. 드라이버, 런타임, 백엔드, 운영체제, 냉각 상태, 전원 설정, 모델 파일 구현에 따라 실제 tokens/sec가 달라질 수 있습니다.

Community Leaderboard는 이 차이를 보완하기 위한 기능입니다. 다른 사용자들이 실제 하드웨어에서 측정한 tokens/sec, time to first token, peak VRAM 사용량 같은 값을 볼 수 있습니다. 내 하드웨어와 같은 결과가 있으면 특히 유용합니다. 같은 GPU에서 같은 모델을 돌린 실제 측정값은 이론 추정보다 체감에 가까운 판단 근거가 됩니다.

다만 커뮤니티 측정값도 맹신하면 안 됩니다. 벤치마크 조건이 다를 수 있고, 사용한 런타임이나 양자화, 컨텍스트 길이가 다를 수 있습니다. 그래서 Leaderboard는 “정답”이라기보다 “현실 보정값”으로 보는 것이 좋습니다. LLM Fit의 추정값으로 후보를 좁히고, 커뮤니티 측정값으로 실제 가능성을 확인한 뒤, 마지막에는 내 장비에서 테스트하는 순서가 가장 안전합니다.

[표 A-7] 추정값과 실측값 비교. 열은 “구분”, “장점”, “한계”, “활용 방법”으로 구성

실무에서는 특히 자동완성 모델을 고를 때 실측값이 중요합니다. 채팅 모델은 조금 느려도 기다릴 수 있지만, 자동완성은 지연이 바로 체감됩니다. 따라서 자동완성 후보는 LLM Fit의 tok/s, 커뮤니티 실측값, 실제 IDE 자동완성 테스트를 모두 거쳐야 합니다.

A.14 모델 다운로드 전 마지막 체크리스트

LLM Fit으로 후보를 고른 뒤에도 바로 다운로드하지 말고 마지막 체크를 하는 습관을 들이는 것이 좋습니다. 모델 파일은 크고, 디스크 공간을 차지하며, 여러 버전을 받다 보면 관리가 어려워집니다. 다운로드 전에 기준을 통과한 모델만 받는 편이 좋습니다.

• 첫째, 목적이 맞는지 확인합니다. 코딩용으로 쓸 모델인데 일반 채팅 모델을 고른 것은 아닌지 봅니다.
• 둘째, Fit 등급을 확인합니다. 초보자는 Good 이상을 우선으로 봅니다.
• 셋째, 양자화를 확인합니다. 너무 낮은 양자화로 겨우 실행되는 큰 모델보다, 조금 작은 모델의 안정적인 양자화가 나을 수 있습니다.
• 넷째, 컨텍스트가 충분한지 봅니다.
• 다섯째, 예상 속도가 작업에 맞는지 봅니다.
• 여섯째, 라이선스를 확인합니다.
• 일곱째, 내가 쓰는 런타임에서 실제로 실행 가능한 포맷인지 확인합니다.

LLM Fit은 다운로드 기능도 제공할 수 있습니다. TUI에서 모델을 선택하고 다운로드할 provider를 고르면 모델 파일을 받을 수 있습니다. 다만 이 책의 중심 워크플로가 LM Studio라면, LLM Fit에서 후보를 고른 뒤 LM Studio에서 같은 모델이나 호환되는 GGUF 모델을 검색해 받는 방식도 가능합니다. 도구는 달라도 선택 기준은 같습니다.

[체크리스트 A-2] 다운로드 전 최종 체크리스트. 항목은 “작업 목적 일치”, “Fit Good 이상”, “Quant Q4 이상 우선”, “컨텍스트 충분”, “예상 tok/s 확인”, “라이선스 확인”, “런타임/포맷 확인”, “디스크 여유 공간 확인”, “테스트 프롬프트 준비”로 구성합니다.

초보자에게 추천하는 다운로드 원칙은, 처음에는 1개만 받지 말고 2~3개 후보를 받습니다. 그러나 10개씩 받지는 않습니다. 후보가 많아지면 비교가 어려워집니다. 자동완성 후보 2개, 채팅 후보 2개 정도면 충분합니다. 실제 프로젝트에서 테스트한 뒤 하나를 기본값으로 정하고, 나머지는 백업 후보로 둡니다.

A.15 실제 코딩 모델 테스트 프롬프트

모델 선택의 마지막 단계는 실제 테스트입니다. LLM Fit은 “이 모델이 내 장비에 맞는가”를 알려 주지만, “내 프로젝트에서 좋은 답을 하는가”는 직접 확인해야 합니다. 테스트는 어렵게 만들 필요가 없습니다. 실제로 자주 하는 작업을 기준으로 짧은 프롬프트를 준비하면 됩니다.

• 첫 번째 테스트는 코드 설명입니다.

아래 TypeScript 함수를 초보 개발자도 이해할 수 있게 설명해 주세요.
단, 함수의 입력, 출력, 예외 상황을 나누어 설명해 주세요.
설명은 10줄 이내로 작성해 주세요.

이 테스트에서는 모델이 코드를 정확히 읽는지, 과장하거나 없는 동작을 만들어 내지 않는지 봅니다. 설명이 유창한 것보다 사실이 맞는지가 중요합니다.

• 두 번째 테스트는 리팩터링입니다.

아래 함수를 리팩터링해 주세요.
조건은 다음과 같습니다.
- 함수의 외부 동작은 바꾸지 않습니다.
- 함수 시그니처는 유지합니다.
- 중복 조건문을 줄입니다.
- 변경 이유를 5줄 이내로 설명합니다.

이 테스트에서는 모델이 코드를 보기 좋게 바꾸면서도 동작을 유지하는지 봅니다. 리팩터링 결과가 그럴듯해도 테스트가 깨지면 실패입니다.

• 세 번째 테스트는 테스트 코드 생성입니다.

아래 함수에 대한 테스트 케이스를 작성해 주세요.
정상 케이스 2개, 경계값 케이스 2개, 예외 케이스 1개를 포함해 주세요.
테스트 프레임워크는 Vitest를 사용합니다.

이 테스트에서는 모델이 경계값을 생각하는지, 프레임워크 문법을 맞게 쓰는지, 실제로 실행 가능한 테스트를 만드는지 봅니다.

• 네 번째 테스트는 버그 분석입니다.

아래 코드와 에러 로그를 보고 가능한 원인을 우선순위대로 3개만 제시해 주세요.
바로 코드를 수정하지 말고, 각 원인을 확인하는 방법을 함께 적어 주세요.

이 테스트에서는 모델이 곧바로 답을 지어내지 않고, 원인 후보와 검증 방법을 분리해서 제시하는지 봅니다. 실무 디버깅에서는 이 태도가 매우 중요합니다.

[표 A-8] 코딩 모델 테스트 결과 기록표.

테스트할 때는 반드시 같은 프롬프트를 여러 후보 모델에 넣어야 비교가 됩니다. 모델 A에는 쉬운 문제를 주고, 모델 B에는 어려운 문제를 주면 공정한 판단이 어렵습니다. 같은 입력, 같은 제한, 같은 평가 기준을 사용해야 합니다.

A.16 목적별 모델 선택 공식

이제 LLM Fit을 활용한 모델 선택 공식을 정리하겠습니다. 처음 로컬 LLM을 고르는 독자에게는 좋은 출발점이 됩니다. 몇 번 여러분이 공식에 맞게 선택하고 테스트 해보시면 모델 선택 하시는 시간이 짧아집니다.

• 자동완성용 모델은 “Speed → Fit → Coding 적합성 → Quant” 순서로 봅니다. 자동완성은 느리면 쓸 수 없습니다. 따라서 tok/s가 높고 Fit이 좋은 모델을 우선합니다. 아주 큰 모델보다 작고 빠른 코딩 모델이 유리합니다. 컨텍스트는 너무 길 필요가 없지만, 현재 함수와 근처 파일을 볼 정도는 필요합니다.

• 채팅용 모델은 “Fit → Quality → Speed → Context” 순서로 봅니다. 코드 설명, 간단한 리팩터링, 문서화, 질문 답변에 쓰는 모델입니다. 너무 느리면 답답하지만, 자동완성만큼 즉시성이 필요하지는 않습니다. 한국어 설명이 필요한 경우 실제 프롬프트로 따로 테스트합니다.

• 리팩터링용 모델은 “Coding 적합성 → Context → Fit → Quality” 순서로 봅니다. 리팩터링은 관련 코드와 테스트를 함께 봐야 하므로 컨텍스트가 중요합니다. 다만 모델이 너무 크고 느리면 반복 작업에 쓰기 어렵습니다. Good 이상 Fit에서 가장 균형 잡힌 코딩 모델을 찾습니다.

• 에이전트용 모델은 “지시 준수 → Coding 적합성 → Context → Fit → Speed” 순서로 봅니다. 에이전트는 파일을 읽고 수정하고 명령을 실행할 수 있으므로, 지시를 잘 따르는 모델이 중요합니다. 모델이 조금 똑똑해 보여도 지시를 무시하거나 파일 범위를 자꾸 벗어나면 위험합니다. 에이전트 작업은 반드시 Git으로 변경 사항을 관리하면서 진행합니다.

• 추론용 모델은 “Quality → Context → Fit → Speed” 순서로 봅니다. 어려운 설계 검토나 복잡한 원인 분석에 사용합니다. 다만 로컬 추론 모델이 너무 느리면 실무에서는 클라우드 모델과 역할을 나누는 편이 낫습니다.

[표 A-9] 목적별 모델 선택 공식. 열은 “목적”, “가장 먼저 볼 것”, “양보 가능한 것”, “피해야 할 후보”, “추천 테스트”로 구성

A.17 30분 안에 모델 선택을 끝내는 실전 절차

마지막으로 실제 절차를 하나로 묶어 보겠습니다. 목표는 30분 안에 내 장비에서 쓸 모델 후보를 고르고, 최소한 하나를 실행 테스트하는 것입니다. 시간은 사람마다 다르지만, 순서는 다음처럼 가져가면 됩니다.

• 먼저 LLM Fit을 설치하고 llmfit system으로 하드웨어 정보를 확인합니다. RAM과 VRAM을 확인하고, GPU가 제대로 감지되는지 봅니다. 다음으로 llmfit을 실행해 TUI를 엽니다. Fit 필터를 Good 이상으로 좁히고, use case를 Coding 중심으로 봅니다. Score와 tok/s로 정렬해 후보를 봅니다.

• 후보 3개를 고릅니다. 하나는 빠른 자동완성 후보, 하나는 균형 잡힌 채팅 후보, 하나는 조금 더 품질이 높은 리팩터링 후보로 잡습니다. 후보가 겹쳐도 괜찮습니다. 좋은 모델 하나가 여러 역할을 맡을 수도 있습니다. 다만 처음부터 너무 많은 모델을 받지는 않습니다.

• 후보를 비교합니다. Fit, tok/s, Quant, Context, Memory %, License를 봅니다. Too Tight는 제외합니다. Marginal은 실험 후보로만 둡니다. Good 이상 중에서 내 목적에 맞는 모델을 고릅니다. 필요하면 Plan mode로 컨텍스트를 바꿨을 때 요구 메모리가 어떻게 변하는지 봅니다.

• 모델을 다운로드합니다. LLM Fit에서 바로 받을 수도 있고, LM Studio나 llama.cpp, Ollama 같은 런타임에서 같은 후보를 찾아 받을 수도 있습니다. 다운로드가 끝나면 실제 프롬프트로 테스트합니다. 코드 설명, 리팩터링, 테스트 생성, 버그 분석 네 가지 중 두세 가지만 해도 충분합니다. 결과가 마음에 들면 그 모델을 Continue의 chat 또는 autocomplete 모델로 연결합니다.

[실습 화면 A-3] “30분 모델 선택 루틴” 화면 구성.

절차를 한 줄로 줄이면 다음과 같습니다.

목적 정의 → 하드웨어 확인 → Good 이상 필터 → 후보 3개 비교 → 다운로드 → 실제 코딩 테스트 → IDE 기본 모델로 지정

이 순서를 지키면 모델 선택이 훨씬 덜 막막해집니다. 로컬 LLM은 선택지가 많아서 어려운 것이지, 원칙이 없는 영역은 아닙니다. 내 장비와 내 작업을 기준으로 보면 후보는 빠르게 줄어듭니다.

A.18 LLM Fit을 쓸 때의 한계와 주의점

LLM Fit은 좋은 도구지만, 모든 판단을 대신해 주지는 않습니다.

• 첫째, 점수는 추정값입니다. 실제 속도와 품질은 내 환경에서 테스트해야 합니다.
• 둘째, 모델 데이터베이스는 업데이트가 필요합니다. 최신 모델이 바로 반영되지 않을 수 있고, 반대로 오래된 정보가 남아 있을 수도 있습니다.
• 셋째, 라이선스 판단은 별도로 해야 합니다.
• 넷째, 코딩 품질은 벤치마크와 다를 수 있습니다. 내 프로젝트의 프레임워크, 언어, 코딩 규칙, 테스트 스타일에 따라 결과가 달라집니다.

또 하나의 주의점은 보안입니다. LLM Fit 자체는 하드웨어와 모델 적합성을 보는 도구입니다. 그러나 모델 다운로드, 런타임 연결, 커뮤니티 벤치마크 조회, 외부 API 사용 여부는 환경에 따라 달라질 수 있습니다. 회사 환경에서 사용할 때는 어떤 네트워크 요청이 발생하는지, 어떤 모델 파일을 어디에서 받는지, 모델 라이선스가 무엇인지 확인해야 합니다.

LLM Fit을 “모델 선택의 첫 관문”으로 보면 가장 좋습니다. 다운로드 전에 후보를 줄이고, 업그레이드 전에 시뮬레이션하고, 추정값과 커뮤니티 실측값을 참고합니다. 그러나 최종 결정은 실제 프로젝트 테스트와 사람의 검토로 내려야 합니다. 로컬 AI는 도구가 아니라 개발 워크플로입니다. 도구가 추천한 모델을 그대로 믿는 것이 아니라, 내 작업 기준으로 검증하는 과정이 필요합니다.

[체크리스트 A-3] LLM Fit 사용 시 주의사항 체크리스트.

로컬 LLM 선택은 감으로 하는 일이 아닙니다. 내 하드웨어, 작업 목적, Fit 등급, 예상 속도, 양자화, 컨텍스트, 라이선스를 함께 보는 일입니다.

LLM Fit은 이 판단을 빠르게 시작하게 해 줍니다. 모델을 다운로드하기 전에 먼저 물어보십시오. “이 모델이 내 컴퓨터에서 실제로 쓸 만하게 돌아갈까?” 이 질문에 답하고 시작하면, 로컬 AI 코딩 환경은 훨씬 안정적으로 구축됩니다.